Mr_rodge, you're not alone.
I also have the same problem with FS.

Simulated GPS on Plan:
If doing a Southerly approach, the Instrument view crashes when close to the airfield.

If doing a Northerly approach to runway 22, I get the same strange extended runway centreline as you did.

Could others try the simulated GPS approaches to ensure that mr_rodge & I haven't got corrupted installations?
(Did a fresh install of SkyDemon 2.1 prior to the tests)

Regards,

Max.

Just to confirm that I tried it om my simulator moded and the same happened, I got an unhandled exception (whatever that means, with these details) if they are any help.

See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.OverflowException: Overflow error.
   at System.Drawing.Graphics.CheckErrorStatus(Int32 status)
   at System.Drawing.Graphics.DrawEllipse(Pen pen, Single x, Single y, Single width, Single height)
   at System.Drawing.Graphics.DrawEllipse(Pen pen, RectangleF rect)
   at Divelements.Aviation.FlyingInstruments.xf47137656ba6e9da.DrawForeground(Graphics graphics, Rectangle bounds)
   at Divelements.Aviation.FlyingInstruments.x51138fd5a5926dca.OnPaint(PaintEventArgs e)
   at System.Windows.Forms.Control.PaintWithErrorHandling(PaintEventArgs e, Int16 layer, Boolean disposeEventArgs)
   at System.Windows.Forms.Control.WmPaint(Message& m)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativewindow.WndProc(Message& m)
   at System.Windows.Forms.Nativewindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

************** Loaded Assemblies **************
mscorlib
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.4952 (win7RTMGDR.050727-4900)
    CodeBase: file:///C:/Windows/Microsoft.NET/Framework64/v2.0.50727/mscorlib.dll
----------------------------------------
SkyDemon
    Assembly Version: 2.1.0.15697
    Win32 Version:
    CodeBase: file:///C:/Program%20Files%20(x86)/Divelements%20Limited/SkyDemon/SkyDemon.exe
----------------------------------------
Divelements.Aviation
    Assembly Version: 1.0.4114.15695
    Win32 Version: 1.0.4114.15695
    CodeBase: file:///C:/Program%20Files%20(x86)/Divelements%20Limited/SkyDemon/Divelements.Aviation.DLL
----------------------------------------
System.Windows.Forms
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.4927 (NetFXspW7.050727-4900)
    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.4927 (NetFXspW7.050727-4900)
    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.4927 (NetFXspW7.050727-4900)
    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
Divelements.SandGrid
    Assembly Version: 2.2.4.1
    Win32 Version: 2.2.4.1
    CodeBase: file:///C:/Program%20Files%20(x86)/Divelements%20Limited/SkyDemon/Divelements.SandGrid.DLL
----------------------------------------
SandDock
    Assembly Version: 3.0.6.1
    Win32 Version: 3.0.6.1
    CodeBase: file:///C:/Program%20Files%20(x86)/Divelements%20Limited/SkyDemon/SandDock.DLL
----------------------------------------
Divelements.Mapping
    Assembly Version: 1.0.4114.15695
    Win32 Version: 1.0.4114.15695
    CodeBase: file:///C:/Program%20Files%20(x86)/Divelements%20Limited/SkyDemon/Divelements.Mapping.DLL
----------------------------------------
System.Xml
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.4927 (NetFXspW7.050727-4900)
    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------
SandBar
    Assembly Version: 1.4.3.1
    Win32 Version: 1.4.3.1
    CodeBase: file:///C:/Program%20Files%20(x86)/Divelements%20Limited/SkyDemon/SandBar.DLL
----------------------------------------
System.Configuration
    Assembly Version: 2.0.0.0
    Win32 Version: 2.0.50727.4927 (NetFXspW7.050727-4900)
    CodeBase: file:///C:/Windows/assembly/GAC_MSIL/System.Configuration/2.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
----------------------------------------

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:

<configuration>
    <system.windows.forms jitDebugging="true" />
</configuration>

When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.

 

I can confirm that we're seeing this here too, and it's do to with the specific way that runway data has been entered for Full Sutton. We'll release a hotfix build within a few days.

Unfortunately I can't see how this can work in practise.



Correct me if I'm wrong but GPS can measure the actual distance between two points (e.g. sea level and the receiver) whereas our altimeters measure/assume our altitude by knowing the difference in two air pressures, the Qnh we give it and the pressure fed to it via our static source. Vary the Qnh and/or the air density and the two measurements are rarely the same.



I have no doubt which is likely to be more accurate but reality dictates we must use an altimeter to define our altitude and it's this that separates us from each other and any airspace infringements. Just because SD shows our level to be clear of an infringement either on "Plan" or "Mobile" it doesn't mean to say if we fly accurately to any V-Nav pointer that it will remain so. Big aeroplanes get round this by having an input from an air data computer so their VNAV Path is actually a pressure level but I'm guessing this is a little beyond Tim & the team?



Cheers BJ

----------------------------------------

HTC HD2/Mio S505 via MioPocket. Robin 340

I think big airliners get around it by flying FL's above the transition altitude. Below the transition level no need for ADC either, you just crank in whatever QNH you're given. As far as I know, FL's are defined based on standard QNH, no need for fancy ADCs ...

Now in terms of altitude and QNH - obviously if the QNH (air pressure) changes, so does your altitude; but then again if the QNH changes you should be informed of it in principle...

So how does that Qnh you've just been given reach your displays/instruments and autopilot? If you can find a way of doing away with ADC's then sell you're idea to Airbus & Boeing and you'll make a fortune.





So the point of my post is how can this be achieved so that the altitude we all work to is reflected by what we see on SD....the only way I can see is if there is a fluke of atmospheric conditions and even then you won't know it!



"Altitudes" are effectively pressure levels, it would be great if SD could show this but unless there is an air pressure input it can't display anything meaningful in this respect. At least with what we do have in SD there is a far more accurate idea of terrain and obstacle clearance than an old fashioned altimeter.



Cheers BJ

----------------------------------------

HTC HD2/Mio S505 via MioPocket. Robin 340

How does the QNH reach the instruments... Hmmm. Good question. Pilot flicking the alt setting to standard? I think you'll find big iron (and small) were flying flight levels way before anyone thought you actually need an ADC to hold an assigned level. All it takes is a static port.

The point of the thread is how can SD show us a relevant vertical deviation pointer and I highlighted why I felt that was not possible or could be confusing. It would be great if it could but I can’t see how without the added complication of an air pressure input. I think you’re letting your fascination with flight levels get in the way and hopefully my examples below will show why……I won’t make it more complicated by bringing temperature into it.



You’re flying along below transition altitude at 5000’ with a Qnh of 993 and SD agrees you’re at about 5000’. Without climbing or descending you pass into airspace that now puts you above transition level so you set 1013.2. What does your aircraft’s altimeter and SD now say? My guess is SD still says 5000’ but your altimeter now indicates about 5550’.



Alternatively, fly at FL80 from a high pressure area (1033) to a low pressure area (993). Is your physical distance AMSL always 8000’ and does SD show you at 8000’ at both ends of the flight? My guess is you’ve changed altitude by about 1100’ and SD will reflect this.



Everyone else feel free to ignore the following bit if you’re bored with our conversation as it’s a little off thread!



Work out the difference between two pressures and you can determine a height/altitude. An old fashioned altimeter does it mechanically and an ADC does it electronically. Both are in abundance, as can be confirmed by a quick look at many websites (Airbus, Boeing, Bombardier, Cesna, Embraer, Garmin, Piper, etc, etc, etc…). ADC’s are used regardless of the pressure setting, they don’t turn on/off dependent on transition level or standard being set. If you want any more help feel free to make it a private message so we’re not cluttering things up here.



Cheers BJ

----------------------------------------

HTC HD2/Mio S505 via MioPocket. Robin 340

BJ, you do have a point in this. All these changes would have to be taken into account in aviation. However, just to have a clearer view of your suggestions, and to help us focus better on the problem at hand, do you know of any PORTABLE GPS navigation sets that factor the changing air pressure automatically into the equation, to give you the accurate reading you mention? If so please direct us to their websites so that we can see how the mechanism, if practicable, can be incorporated into SD.

Very Newbytheway

DurhamTeaseAirport

At the moment, SkyDemon offers the same as most other VFR handhelds which is GPS altitude. Assuming a perfect fix, this is your actual altitude above local mean sea level.

As soon as one switches to flying relative to another datum (1013.25 for example) SkyDemon, and any other GPS without access to static pressure information, can't really help you any more.